Repository navigation
chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) - #153
renovate[bot] wants to merge 1 commit into
Conversation
|
|
Lambda integration test executed with success... client_payload:
|
OpenSSF Scorecard — 7.2/10 ✅
|
914384b to
296f894
Compare
|
Lambda integration test executed with success... client_payload:
|
|
Lambda integration test executed with success... client_payload:
|
296f894 to
5e7618a
Compare
|
Lambda integration test executed with success... client_payload:
|
|
Lambda integration test executed with success... client_payload:
|
5e7618a to
39e3c07
Compare
|
Lambda integration test executed with success... client_payload:
|
|
Lambda integration test executed with success... client_payload:
|
39e3c07 to
51950a8
Compare
|
Important Review skippedBot user detected. To trigger a single review, invoke the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Lambda integration test executed with success... client_payload:
|
|
Lambda integration test executed with success... client_payload:
|
51950a8 to
dc85ae8
Compare
|
Lambda integration test executed with success... client_payload:
|
Note
This PR body was truncated due to platform limits.
This PR contains the following updates:
v0.82.0→v1.1.1Terragrunt: Arbitrary File Deletion via Malicious Module Manifest
CVE-2026-45099 / GHSA-8394-6f8r-whxg / GO-2026-6241
More information
Details
Summary
Terragrunt is vulnerable to an arbitrary file deletion flaw when downloading external modules. If a remote module contains a maliciously crafted
.terragrunt-module-manifestfile, Terragrunt can be tricked into deleting files anywhere on the local filesystem that the Terragrunt process has access to.Impact
This vulnerability impacts users who download and run untrusted or compromised OpenTofu/Terraform modules. The file deletion occurs during the module download and initialization phase, meaning it happens before OpenTofu or Terraform executes.
In a CI/CD environment or automated runner, an attacker-controlled module could delete arbitrary files, causing denial of service in the deployment pipeline. In a local environment, it could lead to the loss of local source code or configuration files.
This vulnerability is a deletion-only primitive; it does not directly allow for arbitrary code execution (RCE) or data exfiltration.
Affected Versions
v1.0.4Patches
This vulnerability has been resolved in Terragrunt version
v1.0.4.All users are strongly advised to upgrade.
Workarounds
If users cannot upgrade immediately, they can mitigate this risk by:
Technical Details
Terragrunt tracks files copied into a downloaded module's working directory using a
.terragrunt-module-manifestfile. During the directory cleanup process, Terragrunt decodes the entries in this manifest and removes the listed files to prepare a fresh directory for OpenTofu/Terraform runs.Previously, Terragrunt trusted the manifest provided by the downloaded module without verifying that the paths scheduled for deletion remained within the boundaries of the module's destination directory. An attacker could forge a manifest containing directory traversal paths, causing the cleanup function to target files outside the cache. The patch introduces a secure boundary check to ensure all cleaned paths remain safely isolated inside the intended manifest folder.
Credit
Terragrunt would like to thank Francesco Sabiu (@fsabiu) for discovering and responsibly disclosing this vulnerability.
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Terragrunt: Arbitrary File Deletion via Malicious Module Manifest in github.com/gruntwork-io/terragrunt
CVE-2026-45099 / GHSA-8394-6f8r-whxg / GO-2026-6241
More information
Details
Terragrunt: Arbitrary File Deletion via Malicious Module Manifest in github.com/gruntwork-io/terragrunt
Severity
Unknown
References
This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).
Terragrunt catalog predictable temp symlink clobber
CVE-2026-64672 / GHSA-wv6g-x823-wx9m / GO-2026-6768
More information
Details
Summary
Terragrunt's
terragrunt catalogcommand clones each repository referenced in your catalog configuration into a temporary working directory. In affected versions, the clone path it derived was deterministic and sat under the shared system temporary directory, in the form<tmp>/catalog-<base64 sha1 of the repo URL>. Because that path was predictable and Terragrunt followed a symlink already present there instead of rejecting it, a local attacker could plant a symlink at that path and cause Terragrunt to delete a directory and re-clone into it outside the intended temporary root.Impact
This affected users who ran
terragrunt catalogon a host they shared with other local users or processes they did not fully trust, such as a multi-user server or a shared CI runner. The attack required a local attacker: a separate local user or process able to write to the shared system temporary directory. It was not remotely exploitable, and the victim had to runterragrunt catalogwhile the attacker's symlink was already in place.Because the predictable path depended only on the repository URL being cataloged and the location of the system temporary directory, the attacker could compute it in advance and plant a symlink there before the victim ran the command. When the victim ran
terragrunt catalog, Terragrunt followed the symlink out of the intended temporary root, deleted an existing<repoName>directory under the attacker-chosen parent, and repopulated that path with the cloned repository contents. All of this happened in the security context of the user running Terragrunt.The attacker controlled the parent directory the symlink pointed to, but not the leaf name: the leaf was fixed to
<repoName>, derived from the repository URL the victim cataloged. The primitive was deletion of an existing<repoName>directory outside the temporary root, followed by a re-clone into that same path. On a single-user machine with no hostile local processes, exposure was minimal.Affected Versions
< v1.1.1Patches
This vulnerability has been resolved in Terragrunt version
v1.1.1.All users are strongly advised to upgrade.
Workarounds
If you cannot upgrade immediately, ensure that you do not allow untrusted parties to control the values of
TMPDIR,TMP, andTEMPin environments where you runterragrunt catalog.Technical Details
When you run
terragrunt catalog, the catalog service iterates over the repositories in your configuration and prepares a local clone of each one. In affected versions, for a given repository URL it built a clone path by hashing the URL and joining the result under the shared system temporary directory:This path was fully determined by the repository URL and the location of the system temporary directory, so anyone else on the machine who knew which repository a victim would catalog could compute it in advance. The catalog service passed this path into its clone preparation step.
As a result, an attacker who placed a symlink at
<tmp>/catalog-<hash>pointing at a directory of their choosing caused both the removal and the re-clone to operate through that symlink. Both landed at<attacker-chosen-parent>/<repoName>, outside the intended temporary root.Terragrunt
v1.1.1no longer derives a predictable clone path, so an attacker can no longer position a symlink at a location known in advance.Credit
We would like to thank (@br0x2) for discovering and responsibly disclosing this vulnerability.
Severity
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:N/VI:H/VA:H/SC:N/SI:N/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Terragrunt catalog predictable temp symlink clobber in github.com/gruntwork-io/terragrunt
CVE-2026-64672 / GHSA-wv6g-x823-wx9m / GO-2026-6768
More information
Details
Terragrunt catalog predictable temp symlink clobber in github.com/gruntwork-io/terragrunt
Severity
Unknown
References
This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).
Release Notes
gruntwork-io/terragrunt (github.com/gruntwork-io/terragrunt)
v1.1.1Compare Source
🐛 Bug Fixes
Chained role assumption for the S3 backend
When AWS credentials were supplied through
--auth-provider-cmdor environment variables, Terragrunt ignored theassume_roleattribute of theremote_stateblock for its own backend operations, such as bootstrapping the state bucket. In cross-account setups this caused access errors, even though OpenTofu/Terraform itself assumed the role correctly during runs.Terragrunt now uses the supplied credentials as the source identity and assumes the configured role on top of them. The same applies to roles configured via the
iam_roleattribute or the--iam-assume-roleflag, and to fetching dependency outputs directly from S3 state.Safer temporary clone directories for
terragrunt catalogTerragrunt now creates a fresh temporary clone directory for each catalog load, rejects symlinked clone roots, and removes catalog clones when the TUI session exits.
Resolve
dependencyoutputs for units that reference a dependency in a hook,extra_arguments, orremote_stateblockResolving a unit's
dependencyoutputs for a downstream unit no longer fails when that unit references its own dependency in:before_hook,after_hook, orerror_hookextra_argumentsblockremote_stateblockPreviously these raised
There is no variable named "dependency"on the downstream unit, and aremote_statereference could crash Terragrunt.Limit IaC engine archive extraction
Terragrunt now protects developer machines and CI runners from engine archives that expand into unexpectedly large amounts of data. If an IaC engine package is unusually large or contains too many files, Terragrunt stops processing it before it can consume excessive disk space.
--filter-allow-destroywith...[]dependent-traversal filters no longer fails--filter-allow-destroy --filter '...[HEAD~1...HEAD]'failed with "Too many command line arguments" or hung when the deleted unit had dependents. Terragrunt now correctly plans and destroys deleted units regardless of whether dependents are included in the run.Fix
findandlistmissing units inside generated stacks for Git-based filtersterragrunt findandterragrunt listwith a Git-based filter (for example--filter '[HEAD^1...HEAD]') now detect units inside generated stacks. Previously they did not generate stacks in the worktrees they create for the comparison, so no unit nested in a generated stack was ever surfaced, whileterragrunt run --allwith the same filter targeted those units correctly.This affected every change that lands inside a generated stack, including a modified
terragrunt.stack.hcl, a change to a unit's own files, and a change to a file the stack reads viaread_terragrunt_configormark_glob_as_read.Stacks are generated only inside the comparison worktrees;
findandliststill do not generate stacks in your current working directory by default.Treat Git source
refvalues strictly as referencesTerragrunt now passes the
reffrom a Git module source to git strictly as a reference when downloading through content-addressable storage. Previously a source whoserefbegan with a git option (for example a value starting with--) could be interpreted by git as an option rather than a reference while fetching the source.Terragrunt now terminates git option parsing before the repository and reference arguments in its
fetch,clone, andls-remoteinvocations, so these values can only ever be read as the repository and reference they are meant to be. Normal refs, branches, tags, and commit SHAs continue to work unchanged.hcl validateresolvesget_original_terragrunt_dir()to the discovered unitterragrunt hcl validateandterragrunt hcl validate --inputsnow resolveget_original_terragrunt_dir()to each discovered unit's own directory instead of the directory the command was launched from. Previously, when the command ran from a parent directory that discovered units in subdirectories, anyread_terragrunt_config()call that built a path relative toget_original_terragrunt_dir()resolved against the wrong directory and failed with "You attempted to run terragrunt in a folder that does not contain a terragrunt.hcl file", even thoughplan,apply, andrun validateworked on the same configuration.Both commands now set the original config path per discovered unit before parsing, matching the behavior of
runandbackend bootstrap, so relative paths resolve against the unit that owns them.Respect
-lockfile=readonlyduring provider cachingWhen you pass
-lockfile=readonlytoinit, Terragrunt no longer generates or updates.terraform.lock.hclwhile warming the provider cache. Previously the cache step could write the lock file before OpenTofu/Terraform ran, so the read-only check always passed and silently defeated the flag.Terragrunt now leaves the lock file untouched and lets OpenTofu/Terraform enforce it, failing when the lock file is missing or incomplete. The flag is honored whether it is supplied on the command line or through the
TF_CLI_ARGSorTF_CLI_ARGS_initenvironment variables.run --allno longer crashes on dependency discovery with graph filtersRunning
run --allwith a filter that expands a git range through the dependency graph (for example[HEAD~1...HEAD]...) could fail during dependency discovery, reporting that a component "is missing its working directory". Whether it happened depended on the size and shape of the changed unit's dependency closure, so the same filter succeeded on smaller branches andfindwas unaffected.A dependency reached from several units at once could become visible to discovery before its working directory was set, so a concurrent traversal could read it before it was complete. Dependencies now have their working directory set before they become visible, so
run --allbehaves the same regardless of graph size.terraform_binaryrespected byrun --allwhen bothtofuandterraformare onPATHrun --allignored a unit'sterraform_binarysetting and fell back to the auto-detected default (OpenTofu when both binaries are onPATH). The per-unit options used to execute each unit are cloned from the stack options, whose binary path is the auto-detected default, and the configured value was never applied to them.Each unit now honors its own
terraform_binary, matching the behavior of a singlerun. Setting--tf-pathorTG_TF_PATHstill takes precedence over the config value.S3 bucket creation failures report the underlying error
When creating the state bucket failed during backend bootstrap, the reported error was a misleading
NoSuchBucketfrom a follow-up access check, hiding the actual cause. The original creation error, such asAccessDenied, is now part of the reported message.Allow empty
localsblocks interragrunt.stack.hclFixed a bug where an empty
locals {}block in a stack configuration could breakstack generate.Clear error when
terraform.sourcereferences a dependency outputA
terraform.sourcethat referencesdependency.<name>.outputs.<key>is now rejected with a message explaining that the module source must be resolvable before dependencies are evaluated.Terragrunt resolves the source while discovering units and building the run queue, before any dependency has run, so such a source can never be satisfied. Previously it surfaced a cryptic decode error.
🧪 Experiments Added
oci- Module sources from OCI registriesThe
ociexperiment has been added as the gate for downloading source code (including OpenTofu modules) from OCI Distribution registries usingoci://schema URLs in Terragrunt configurations (includingterraform.sourceattributes). This targets the same registries OpenTofu 1.10 supports natively, such as Amazon ECR, GitHub Container Registry, Azure Container Registry, Google Artifact Registry, and self-hosted or air-gapped registries.Enabling the experiment has no behavioral effect yet: the getter that will resolve
oci://sources is not wired into source downloading, sooci://sources still fail to download. Functional support will land in follow-up releases, gated by this experiment.For setup steps, see the experiment documentation.
version-attribute- Resolve registry modules from a version constraintThe
version-attributeexperiment has been added to gate a newversionattribute on theterraformblock. It holds a version constraint (such as~> 3.3or>= 1.0.0, < 2.0.0) for atfr://registry module, and Terragrunt resolves it to the highest published version that satisfies the constraint before downloading:This brings the
terraformblock to parity with theversionargument on OpenTofu and Terraformmoduleblocks. The attribute applies totfr://sources only, and cannot be combined with an inline?version=on the same source.Enable it with
--experiment version-attribute. For setup steps and the criteria for stabilization, see the experiment documentation.⚙️ Process Updates
Friendly panic reports
Terragrunt now writes a
terragrunt-crash-YYYYMMDDTHHMMSSZ-<pid>.logfile when it crashes.The report includes runtime details, the command line, the panic message, and the stack trace. You can conveniently share this file (after reviewing for sensitive information) to report panics if Terragrunt crashes.
Pull Requests
✨ Features
versionattribute on theterraformblock by @yhakbar in #6475🐛 Bug Fixes
-lockfile=readonlyby @yhakbar in #6358--filter-allow-destroywith graph + Git expression combo by @yhakbar in #6322find/listby @yhakbar in #6362terraform_binaryfrom being ignored inrun --allby @yhakbar in #6460stack generateby @yhakbar in #6470run --allwith graph expression throwing on missing working dir by @yhakbar in #6474📖 Documentation
version-attributeexperiment by @yhakbar in #6476🧹 Chores
versionattribute experiment by @yhakbar in #6463sourcefromversionattribute error by @yhakbar in #6480📝 Other Changes
v1.1.0Compare Source
✨ New Features
Stack dependencies
A stack generates a tree of units from a single
terragrunt.stack.hclfile. Wiring one of those units to another used to mean definingdependencyblocks in your catalog and threading dependency paths throughvalues. Stack dependencies let you declare those relationships up front instead.Add an
autoincludeblock inside aunitorstackblock, and Terragrunt generates a partial configuration (aterragrunt.autoinclude.hclfile) next to the generatedterragrunt.hclorterragrunt.stack.hclthat's automatically merged into the unit or stack definition. The newunit.<name>.pathandstack.<name>.pathreferences resolve to generated paths, so you don't have to hardcode them:Anything that's valid in a unit configuration is valid in its
autoincludeblock, so you can also patch catalog units with configuration they don't ship with, like retry rules:The same works for nested stacks: an
autoincludeblock inside astackblock patches the generatedterragrunt.stack.hcl, so you can, for example, add an extra unit to one environment without forking the stack in your catalog.Stack configurations also gained two capabilities along the way:
includeblocks now work interragrunt.stack.hclfiles, so shared stack configuration can live in a parent folder.dependencyblocks can target stack directories, and the run queue expands them to the units inside. Note that this relationship only goes one way: units can depend on stacks, but stacks cannot depend on stacks or units.See the stacks documentation for the full reference. Previously gated behind the
stack-dependenciesexperiment, all of this is now enabled by default.Content Addressable Store (CAS)
The Content Addressable Store (CAS) deduplicates source downloads across configurations. It addresses repositories and modules by their content, stores them locally, and serves later requests from that local store instead of repeating the fetch. This speeds up catalog cloning, OpenTofu/Terraform source fetching, and stack generation, and identical files occupy disk space once regardless of how many configurations use them.
The CAS is no longer limited to Git. It also deduplicates HTTP, Amazon S3, Google Cloud Storage, Mercurial, and SMB sources, along with OpenTofu/Terraform registry sources fetched via
tfr://. See supported sources for how each one resolves and deduplicates content.CAS is enabled by default. Use the
--no-casflag (orTG_NO_CAS=true) to opt out of it for a run:Two new attributes give you finer control, and both default to off:
update_source_with_casmakes a generated stack self-contained. Set it on aunit,stack, orterraformblock with a relativesource, andterragrunt stack generaterewrites that source into a content-addressedcas::reference, so the generated tree no longer depends on the surrounding repository layout. Catalog authors can keep relative paths in their sources and still ship a portable, reproducible stack:After
terragrunt stack generate, the relative path is replaced by a reference to the exact tree the CAS stored:mutablecontrols how the CAS places fetched content on disk. By default, the CAS hard links files from its shared store into.terragrunt-cacheand marks them read-only, which is fast and uses no extra space, but means the files can't be edited in place. Setmutable = trueon aterraformblock to copy the content instead, making the working tree safe to edit at the cost of extra I/O and disk space:Previously gated behind the
casexperiment, the CAS no longer requires--experiment cas.Redesigned
terragrunt catalogThe
catalogcommand has been redesigned. It now starts without any configuration, discovers components across your catalog repositories in the background, and streams them into the TUI as they're found.Discovery is no longer limited to a
modules/directory; components can live anywhere in a catalog repository. To control what gets discovered, add a.terragrunt-catalog-ignorefile with.gitignore-style globs for the paths you want filtered out.Components in the TUI now carry metadata to help you navigate a large catalog: each one shows a kind label (
template,stack,unit, ormodule) and optional tags defined in the front-matter of itsREADME.md. From the component list, presssto open a new screen that interactively collects the values used to scaffold the component into your repository.Previously gated behind the
catalog-redesignexperiment, the redesigned catalog is now the defaultterragrunt catalogexperience.Reading detection for local module sources
Terragrunt can select units by the files they read, which is the basis of change-based runs in CI. Previously, pointing a unit's
terraformblock at a local directory didn't mark the files inside that directory as read, so a change to the module wouldn't select the unit.When a unit's source is a local module, Terragrunt now records the module's
*.tf,*.tf.json,*.hcl,*.tofu, and*.tofu.jsonfiles as read by that unit, so--filter 'reading=<path>'and--queue-include-units-readingselect the unit when a module file changes:terragrunt run --all --filter 'reading=./modules/vpc/main.tf' -- planFor files that reading detection doesn't track on its own, the new
mark_glob_as_read()HCL function expands a glob and marks every matching file as read in one call:Existing pipelines built on
--queue-include-units-readingorreading=filters may select more units than before, because changes to local module files now count as reads. Previously gated behind themark-many-as-readexperiment, these behaviors no longer require--experiment mark-many-as-read.Skip auth during discovery with
--no-discovery-auth-provider-cmdBy default, Terragrunt runs your
--auth-provider-cmdonce for every unit it discovers, so HCL functions that need credentials resolve correctly during parsing. In a large repository, that can mean hundreds of invocations before any unit runs, which can dominate wall-clock time on change-based runs.The
--no-discovery-auth-provider-cmdflag (env:TG_NO_DISCOVERY_AUTH_PROVIDER_CMD) skips those invocations during the discovery phase, leaving auth to run only for the units that actually execute:Previously gated behind the
opt-out-authexperiment, the flag now works without--experiment opt-out-auth.Run queue displayed as a dependency tree
Before a
run --all, Terragrunt lists the units it's about to run. That list now renders as a dependency tree by default instead of a flat list, with units nested under their dependencies, so the run order and the relationships between units are visible before anything executes:The header adapts to direction: dependencies come before dependents on apply, and the order reverses on destroy.
Previously gated behind the
dag-queue-displayexperiment, the tree display no longer requires--experiment dag-queue-display.💡 Tips Added
Tip when filtering a stack leaves nested stacks ungenerated
terragrunt stack generate --filter './my-stack | type=stack'generates only the selectedstack, not the nested stacks it contains, which can be surprising for a stack of stacks.
When a non-glob
| type=stackfilter leaves a stack's nested stacks ungenerated, Terragruntnow prints a tip showing how to generate them too, for example
--filter './my-stack | type=stack' --filter './my-stack/** | type=stack'.🐛 Bug Fixes
Fix
permission deniedwhen generated files overwrite CAS-materialized filesWith the CAS enabled, Terragrunt fetches sources as read-only files. Writing a generated file over one of them no longer fails with
permission denied:generateblocks withif_exists = "overwrite", when the module ships the target file (for example, its ownversions.tf).terragrunt.values.hcl, when the unit or stack source already contains one.terragrunt.autoinclude.hcl, when the unit or stack source already contains one..terraform.lock.hcl, when the provider cache server updates a committed lock file duringinit -upgrade.In each case, the read-only file is replaced with a writable one, and the shared CAS store is never modified.
Fix
permission deniedwhen CAS fetches a git source across filesystemsWith the CAS enabled, fetching a
git::source could fail withpermission deniedon.git/HEADor.git/config, sending Terragrunt back to the standard getter. It happened when the CAS store and the module's working directory sit on different filesystems, so the files are copied rather than hard-linked, and a read-only leftover from an interrupted run was in the way. Terragrunt now recovers from the leftover and completes the fetch.Reject
update_source_with_cason aterraformblock when CAS is disabledterragrunt stack generate --no-casnow fails when a generated unit'sterraformblock setsupdate_source_with_cas = true, instead of silently emitting the unit with its relativesourceunchanged. The relative source has no meaning once CAS is disabled, so the generated unit could not resolve its module. This matches the existing behavior for the same attribute onunitandstackblocks, and for aruninvoked with--no-cas.Apply
extra_argumentsenv vars when resolvingdependencyoutputsResolving a
dependencyblock's outputs now applies theenv_varsfrom the unit'sterraformextra_argumentsblocks whosecommandsincludeoutput.Resolve
dependencyoutputs for units whosebefore_hookreferences a dependencyResolving a unit's
dependencyoutputs no longer evaluates that unit'sterraformhooks, so abefore_hook(orafter_hook) that interpolates${dependency.<name>.outputs.<key>}no longer fails downstream units withThere is no variable named "dependency". Dependency output resolution still applies the unit'sextra_argumentsenv_varsandsource.Select units reading added or deleted glob files in Git-based filters
Git-based filters (for example
terragrunt run --all --filter '[HEAD^1...HEAD]' -- plan) now select unitsthat read an added or deleted file through
mark_glob_as_read, even when that file lives outside the unit'sown directory. Previously only modified files outside a unit reached those units; adding or deleting a file
the glob matched left the reading unit out of the run, so its real config change was skipped. Added files are
matched against the newer reference, and deleted files against the older one where the file still exists.
mark_glob_as_readconstrains its walk to a boundarymark_glob_as_readnow confines glob expansion to a boundary directory. By default the boundary is the enclosing Git repository root; outside a Git repository it is unset. A pattern whose walk would begin outside the boundary returns an error instead of expanding.This bounds patterns that resolve higher than intended. For example,
"${local.dir}/{*.yaml}"becomes/{*.yaml}whenlocal.diris empty, which previously walked the entire filesystem. A? :conditional does not prevent this, because HCL evaluates both branches of a conditional before selecting one. Wrapping the call intrylets the error fall back to a default:Pass a leading
--terragrunt-boundaryargument to set the boundary explicitly, for example to scope the walk to a subdirectory or to widen it to the filesystem root:Scaffold only detects variables in the module directory
terragrunt scaffoldnow reads input variables from the module directory itself, matching what OpenTofu and Terraform load for a root module. Previously it scanned subdirectories too, sovariableblocks defined in nested modules or examples leaked into the scaffolded inputs even though the module never exposes them.Resolve interpolated object keys in autoinclude blocks
terragrunt stack generatenow resolves interpolated object keys inautoincludeblocks (for example{ "${local.prefix}_key" = ... }), even when the value referencesdependency.*. Previously the generatedunit kept the key verbatim, leaking a stack-only reference that is not valid in the unit scope.
Fix panic on non-string literal interpolation in
autoincludetemplatesterragrunt stack generateno longer panics when anautoincludetemplate interpolates a non-string literal (for example"${0}"or"${true}") alongside adependency.*reference. The interpolated literal is now rendered to its string form (${0}becomes0) and the dependency reference is preserved for the unit.Resolve transitive
autoincludedependencies on a stack directoryrun --allno longer fails with "does not contain a terragrunt.hcl file" when anautoincludedependency points at a stack directory (one holdingterragrunt.stack.hcl) and the unit is reached transitively through another unit. The dependency cycle check now skips a target with no unit config, matching the direct dependency case.🧪 Experiments Updated
Six experiments completed
The following experiments graduated to general availability in this release, and the features they gated are now enabled by default:
stack-dependenciescascatalog-redesignmark-many-as-readopt-out-authdag-queue-displayEach feature is described in the New Features section above.
The corresponding
--experimentflags (andTG_EXPERIMENTvalues) are no longer needed. Passing one still works, but emits a warning about the completed experiment, so you can drop it at your convenience.Thank you to everyone who ran these experiments early and filed the feedback that got them here.
⚙️ Process Updates
Immutable releases
Starting with this release, Terragrunt releases are published as immutable releases on GitHub. Once a release is published, its tag and assets can no longer be modified or deleted, so the binary you download is guaranteed to be the same binary that was uploaded when the release was published.
See the releases process documentation for details, and Verifying releases with the GitHub CLI for how to check a download against the release attestation.
Install script verifies release attestations
The install script now checks downloaded release assets against the release attestation that ships with immutable releases. For releases starting with
v1.1.0, when an authenticated GitHub CLI (v2.81.0 or later) is available, the script verifies the checksums file and the binary against the attestation before installing, and aborts if either does not match the published release. The check is skipped with a warning whenghis unavailable, too old, or unauthenticated. Use--no-verify-attestationto opt out.Pull Requests
✨ Features
🐛 Bug Fixes
update_source_with_casintegration with--no-casby @yhakbar in #6363--terragrunt-boundarytomark_glob_as_readby @yhakbar in #6351📖 Documentation
--parallelismtweaking considerations better by @yhakbar in #6313v1.1.0changelog polish by @yhakbar in #6333🧹 Chores
mark-many-as-readexperiment by @yhakbar in #6310casexperiment by @yhakbar in #6254dag-queue-displayexperiment by @yhakbar in #6320opt-out-authexperiment by @yhakbar in #6321go-gitby @yhakbar in #6325catalog-redesignexperiment by @yhakbar in #6271lllby @yhakbar in #6377TestWindowsTflintIsInvokedby @yhakbar in [#6382](htConfiguration
📅 Schedule: (UTC)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.